I feel like I m taking a big personal risk writing this, even though I know the internet is large and probably no-one will read this
.
So, dear reader, please be gentle.
As we grow as people, as developers, as professionals some lessons are are hard to learn (e.g. you have to keep trying and trying to learn the task), and some are hard to experience (they might still be hard to learn, but just being there is hard itself ) I want to talk about a particular lesson I started learning in late 2008/early 2009 while I was at
Canonical sadly one of those that was hard to experience.
At the time I was one of the core developers on Bazaar, and I was feeling pretty happy about our progress, how bzr was developing, features, community etc. There was a bunch of pressure on to succeed in the marketplace, but that was ok, challenges bring out the stubborn in me
. There was one glitch though we d been having a bunch of contentious code reviews, and my manager (
Martin Pool) was chatting to me about them.
I was as far as I could tell doing precisely the right thing from a peer review perspective: I was safeguarding the project, preventing changes that didn t fit properly, or that reduced key aspects- performance, usability from landing until they were fixed.
However, the folk on the other side of the review were feeling frustrated, that nothing they could do would fix it, and generally very unhappy. Reviews and design discussions would grind to a halt, and they felt I was the cause. [They were right].
And here was the thing I simply couldn t understand the issue. I was doing my job; I wasn t angry at the people submitting code; I wasn t hostile; I wasn t attacking them (but I was being shall we say frank about the work being submitted). I remember saying to Martin one day look, I just don t get it can you show me what I said wrong? and he couldn t.
Canonical has a 360 review system every 6 months / year (it changed over time) you review your peers, subordinate(s) and manager(s), and they review you. Imagine my surprise I was used to getting very positive reports with some constructive suggestions when I scored low on a bunch of the inter-personal metrics in the review. Martin explained that it was the reviews thing folk were genuinely unhappy, even as they commended me on my technical merits. Further to that, he said that I really needed to stop worrying about technical improvement and focus on this inter-personal stuff.
Two really important things happened around this time. Firstly,
Steve Alexander, who was one of my managers-once-removed at the time, reached out to me and suggested I read a book
Getting out of the box and that we might have a chat about the issue after I had read it. I did so, and we chatted. That book gave me a language and viewpoint for thinking about the problem. It didn t solve it, but it meant that I got it , which I hadn t before.
So then the second thing happened we had a company all hands and I got to chat with
Claire Davis (head of HR at Canonical at the time) about what was going on. To this day the sheer embarrassment I felt when she told me that the broad perception of me amongst other teams managers was and I paraphrase a longer, more nuance conversation here technically fantastic but very scary to have on the team will disrupt and cause trouble .
So, at this point about 6 months had passed, I knew what I wanted I wanted folk to want to work with me, to find my presence beneficial and positive on both technical and team aspects. I already knew then that what I seek is technical challenges: I crave novelty, new challenges, new problems. Once things become easy, it call all too easily slip into tedium. So at that time my reasoning was somewhat selfish: how was I to get challenges if no-one wanted to work with me except in extremis?
I spent the next year working on myself as much as specific projects: learning more and more about how to play well with others.
In June 2010 I got a performance review I could be proud of again I was in no way perfect, but I d made massive strides. This journey had also made huge improvements to my personal life a lot of stress between Lynne and I had gone away. Shortly after that I was invited to apply for a new role within Canonical as Technical Architect for
Launchpad and
Francis Lacoste told me that it was only due to my improved ability to play well with others that I was even considered. I literally could not have done the job 18 months before. I got the job, and I think I did pretty well in fact I was awarded an internal Spotlight on Success award for what we (it was a whole Launchpad team team effort) achieved while I was in that role.
So, what did I change/learn? There s just a couple of key changes I needed to make in myself, but a) they aren t sticky: if I get overly tired, ye old terrible Robert can leak out, and b) there s actually a /lot/ of learnable skills in this area, much of which is derived lots of practice and critical self review is a good thing. The main thing I learnt was that I was Selfish. Yes capital S. For instance, in a discussion about adding working tree filter to bzr, I would focus on the impact/risk on me-and-things-I-directly-care-about: would it make my life harder, would it make bzr slower, was there anything that could go wrong. And I would spend only a little time thinking about what the proposer needed: they needed support and assistance making their idea reach the standards the bzr community had agreed on. The net effect of my behaviours was that I was a class A asshole when it came to getting proposals into a code base.
The key things I had to change were:
- I need to think about the needs of the person I m speaking to *and not my own*. [Thats not to say you should ignore your needs, but you shouldn't dwell on them: if they are critical, your brain will prompt you].
- There s always a reason people do things: if it doesn t make sense, ask them! [The crucial conversations books have some useful modelling here on how and why people do things, and on how-and-why conversations and confrontations go bad and how to fix them.]
Ok so this is all interesting and so forth, but why the blog post?
Firstly, I want to thank four folk who were particularly instrumental in helping me learn this lesson: Martin, Steve, Claire and of course my wife Lynne I owe you all an unmeasurable debt for your support and assistance.
Secondly, I realised today that while I ve apologised one on one to particular folk who I knew I d made life hard for, I d never really made a widespread apology. So here it is: I spent many years as an ass, and while I didn t mean to be one, intent doesn t actually count here actions do. I m sorry for making your life hell in the past, and I hope I m doing better now.
Lastly, if I m an ass to you now, I m sorry, I m probably regressing to old habits because I m too tired something I try to avoid, but it s not always possible. Please tell me, and I will go get some sleep then come and apologise to you, and try to do better in future.
Less-assily-yrs,
Rob
Recently I was doing some work on the alioth infrastructure like fixing things or cleaning up things.
One of the more visible things I done was the switch from gitweb to cgit. cgit is a lot of faster and looks better than gitweb.
The list of repositories is generated every hour. The move also has the nice effect that user repositories are available via the cgit index again.
I don t plan to disable the old gitweb, but I created a bunch of redirect rules that - hopefully - redirect most use cases of gitweb to the equivalent cgit url.
If I broke something, please tell me, if I missed a common use case, please tell me. You can usually reach me on #alioth@oftc or via mail (formorer@d.o)
People also asked me to upload my cgit package to Debian, the package is now waiting in NEW. Thanks to Nicolas Dandrimont (olasd) we also have a patch included that generates proper HTTP returncodes if repos doesn t exist.
As Jan has previously 
In case you have spare time at the weekend ahead, it may be worth to spend it with great 
I thought it would have been smooth, though it wasn t. OpenRC shipped /sbin/rc, which conflicted with the rc shell (an implementation of the AT&T Plan 9 shell), and /sbin/runscript was conflicting with minicom. With the help of upstream authors, /sbin/rc was renamed /sbin/openrc, and /sbin/runscript was renamed /sbin/openrc-run.
However, the main goal is reached: after last summer Google Summer of Code project, and a bit of rework for the ruff edges, OpenRC made it to Debian.
So, if you wish to try OpenRC, which is a direct replacement for sysv-rc, just add the Debian Experimental repository to your sources.list, and do apt-get install openrc . The only issue will be the first reboot, though that should be fine if one manually shuts down every running daemon, and then type what the postinst suggests as command echoed on the screen. Suggestions on how to improve this is welcome. I warmly also welcome more general feedback.
I d like to publicly thank Patrick Lauer, Benda ( ), WIlliam Hubbs, Alexander Vershilov (who are all OpenRC upstreams), Bill Wang who was the GSoC studdent working on OpenRC, Roger Leigh who is the current sysv-init/sysv-rc maintainer, for their help and support when porting OpenRC to Debian. Without them, it wouldn t have been possible.
As you know, I am not big on reviews, so you should disregard the
remainder of this entry.
I recently found myself in what is called a theatre complex ,
watching an adaptation of Moli re's Les Femmes savantes by
Freyda Thomas, who is apparently famous for playing Alenis
Grem on Deep Space Nine.
Called The Learned Ladies, this translation to English
manages to approximate some of the rhyme of the original,
thereby making it unquestionably better than DS9.
Also noteworthy is the all-female cast, cobbled together
from two all-female theater groups. Elizabeth Neptune
plays Chrysale, occasionally channeling the spirit of
Jackie Gleason or bringing adorable ardor to such epic
lines as Tea! I won't say anything about her eyes, but
I will say something about her slippers.
Sara Montgomery, as B lise, is delightfully crazy in
her singing, dancing, costume changes, and other antics,
which serve to transform this otherwise-completely-serious
play into a comedy. I definitely won't say anything about her
shoes.
Madeleine Maby begins playing Philaminte well before
the show starts. Spoiler alert: she sits on the stage,
pretending to look through a telescope and make notes
from before the house opens until right before the start
of the first scene. I still feel exhausted by the thought
of having to do that myself.
L' pine is portrayed by Alyssa Lott, who also plays three
minor roles. Her mastery of physical comedy is not wasted
on this production.
Marta Kuersten plays Clitandre opposite Sarah Brill's
Henriette. While Marta's performance was quite good, she
looks much better as a woman. I will not be saying this
about everyone.
Katie Honaker delivers visceral smarm and sleaze as
Trissotin. Even her hairstyle is somehow evocative of
contempt.
Susan Finch plays Vadius and Le notaire. Susan was definitely
most convincing as a man. Despite mutterings to the
contrary, some suspension of disbelief was necessary for the
other male roles, but not for Vadius, oh no.
Finishing out the list we have Janna Emig as Martine,
Francesca Day as Armande, and Kathryn Alexander as Ariste,
with good performances, particularly in the second half.
Even though it didn't have Coppertop from Strangers With Candy
and a boy-band song-and-dance cover of To Be with You by Mr. Big,
I recommend this play.
A work-related blog post for a change, but still about Haskell. My student Alexander Kuhnle has submitted his bachelor thesis 
The GUI is written using the PyQT Toolkit and the options in the GUI are generated at runtime, based on the list of available power saving modules.
Apart from the GUI configuration tool, this release also includes some bug fixes:
One of my own contributions to the project has been the creation of